Lance Spitzner
Last Modified:  30 June, 1999
 
Firewalls are one of the fastest growing technical tools in the field of information security. However, a firewall is only as secure as the operating system it resides upon. This article will take a step by step look at how you can best armor your Solaris box, both Sparc and x86. These steps can apply to any situation, however I will be using Check Point FireWall-1 on Solaris 2.6 as an example.  At the end of this article is a script that you can download that will automate most of the armoring process, to include implementing TCP Wrappers.

Installation
The best place to start in armoring your system is at the beginning, OS installation. Since this is your firewall, you cannot trust any previous installations. You want to start with a clean installation, where you can guarantee the system integrity.

Place your system in an isolated network. At no time do you want to connect this box to an active network nor the Internet, exposing the system to a possible compromise. To get critical files and patches later, you will need a second box that acts as a go between. This second box will download files from the Internet, then connect to your isolated, configuration "network" to transfer critical files.

Once you have placed your future firewall box in an isolated network, you are ready to begin. The first step is selecting what OS package to load. I recommend End User with On-line manual pages. The idea is to load the minimum installation, while maintaining maximum efficiency. The less software that resides on the box, the fewer potential security exploits or holes. Anything above the End User package, such as Developer, is adding useless but potentially exploitable software. Remember this is your firewall, it should be running nothing else.

The other option is to load the Core installation package, which is smaller and leaner then the End User installation. However, you must know exactly what you are doing, as the Core package may be missing critical executables or libraries. Usually you will have to add specific packages. I prefer End User installation, as it tends to be more stable and flexible. Regardless of which installation you choose, I would add the manual pages.  I find the on-line man pages to be a critical resource that add little risk to your system.

During the installation process, you will be asked to partition your system.   I've never really understood Sun's love for making various partitions, specifically /opt and /usr.  You always end up making the partitions to small and running out of room later.  I always like to make root as big as possible and just throw everything in there, then you do not run out of room.  However, we  do need several partitions to protect the root drive.  If we were to fill the root partition with data, such as logging or email, we would cause a denial of service, potentially crashing the system.

Therefore, I always recommend a separate partition for /var, this is where all the system logging and email goes.  By isolating the /var partition, you protect your root partition from overfilling.   I've found 200 MB to be more then enough for /var.  You may also consider making a separate partition for the firewall logging.  For Checkpoint Firewall 1, all logging by default happens in /etc/fw/log.  Many Solaris systems have two or more drives, such as the Ultra 10 or 2 IDE drives for an x86.  If you are not mirroring the second drive, make it the partition for all the firewall logging.  Once again, this protects all the other partitions in case the firewall logging floods the drive. With such a setup, your partitions would look as follows:

/               - everything else
/var            - 400 MB
swap            - 256 MB (or normally 2x amount of RAM)
/etc/fw/log           - 2nd drive (for CP FW1 ver 3.0x)
/var/opt/CKPfw/log    - 2nd drive (for CP FW1 ver 4.0x)

Once the system has rebooted after the installation, be sure to install the recommend patch cluster and security patches from Sun. Be sure to use your go between box to get the patches, the firewall box should always remain on an isolated network. Patches are critical to armoring a system and should always be updated.  BUGTRAQ is an excellent source for following bugs and system patches.
 

Eliminating Services
Once you have loaded the installation package, patches, and rebooted, we are now ready to armor the operating system. Armoring consists mainly of turning off services, adding logging, tweaking several files, and TCP Wrappers. First we will begin with turning off services.

By default, Solaris is a powerful operating system that executes many useful services. However, most of these services are unneeded and pose a potential security risk for a firewall. The first place to start is /etc/inetd.conf. This file specifies which services the /usr/sbin/inetd daemon will listen for. By default, /etc/inetd.conf is configured for 35 services, you only need two, ftp and telnet. You eliminate the remaining unnecessary services by commenting them out (example).  This is critical, as many of the services run by inetd pose serious security threats, such as rexd.  Confirm what you have commented out with the following command (this will show you all the services that were left uncommented)

 #grep -v "^#" /etc/inetd.conf

The next place to start is /etc/rc2.d and /etc/rc3.d. Here you will find startup scripts launched by the init process. Many of these are not needed. To stop a script from starting, replace the capital S with a small s. That way you can easily start the script again just by replacing the small s with a capital S. The following scripts are not needed and pose serious security threats to your system.

S73nfs.client - used for NFS mounting a system. A firewall should never mount another file system.

S74autofs - used for automounting, once again, a firewall should never mount another file system.

S80lp - used for printing, your firewall should never need to print.

S88sendmail - This is the MTA daemon that listens for incoming email. Your firewall box should not be your email server. However, your system will still be able to send mail, such as alerts.

../rc3.d/S15nfs.server - used to share file systems, a bad idea for firewalls.

../rc3.d/S76snmpdx - snmp daemon

 Later, when you have completed both the OS and Firewall installation and configuration, there are two other /etc/rc2.d scripts you should turn off.

S99dtlogin - CDE daemon, starts CDE or OpenWindows by default

S71rpc - portmapper daemon

Without these scripts, you cannot launch a gui interface. You most likely will want the gui interface to help you with the installation and configuration. However, once your are done, there is no need for the gui, nor either of the scripts. Both rpc and OpenWindows or CDE have many exploitable ports and services. To see how many services are running with both the gui and rpc running, type the command

ps -aef | wc - l

Once you are done with the installation and have turned off S99dtlogin and S71rpc, type the command again and compare how the number of services have decreased. The fewer services running, the better.

Logging and Tweaking
Once you have eliminated as many services as possible, we want to enable logging. Most system logging occurs in /var/adm. We want to add two additional log files there, sulog and loginlog. /var/adm/sulog logs all su attempts, both successful and failed. This allows you to monitor who is attempting to gain root access on your system.

 /var/adm/loginlog logs consecutive failed login attempts. When a user attempts to login 5 times, and all 5 attempts fail, this is logged. To enable the files, just touch the files /var/adm/loginlog and /var/adm/sulog. Ensure both files are chmod 640, as they contain sensitive information.

Next comes tweaking. This involves various file administration. The first thing we want to do is create the file /etc/issue. This file is an ASCII text banner that appears for all telnet logins (example A). This legal warning will appear whenever someone attempts to login to your system.

We also want to create the file /etc/ftpusers (example B). Any account listed in this file cannot ftp to the system. This restricts common system accounts, such as root or bin, from attempting ftp sessions. The easiest way to create this file is the command

cat /etc/passwd | cut -f1 -d: > /etc/ftpusers

Ensure that any accounts that need to ftp to the firewall are NOT in the file /etc/ftpusers.

Also, ensure that root cannot telnet to the system. This forces users to login to the system as themselves and then su to root. This is a system default, but always confirm this in the file /etc/default/login, where console is left uncommented (example C).
 

TCP Wrappers
TCP Wrappers are a must for any firewall, no armored system should be without it. Created by Wietse Venema, TCP Wrappers are a binary that wraps itself around inetd services, such as telnet or ftp. With TCP Wrappers, the system launches the wrapper for inetd connections, which logs all attempts and verifies the attempt against a access control list. If the connection is permitted, TCP Wrappers hands the connection to the proper binary, such as telnet. If the connection is rejected by the access control list, then the connection is dropped.

Many of you may be wondering why would a firewall need TCP Wrappers, the firewall does all that for you. The answers are simple. First, in case the firewall is compromised or crashes, TCP Wrappers offer a second layer of defense. Second, and just as important, TCP Wrappers protect against Firewall misconfigurations. I have often seen firewalls misconfigured, especially in VPN situations, allowing unauthorized users telnet access to the firewall. Third, TCP Wrappers add a second layer of logging, verifying other system logs.

You can get TCP Wrappers from http://coast.cs.purdue.edu/pub/tools/unix. Once again, be sure to use your go between system to retrieve and compile TCP Wrappers. We do not want any compilers on the Firewall and we want to protect the armored Solaris box within its isolated network.

Once downloaded, be sure to review the README file first, it is an excellent introduction to TCP Wrappers. Two options I recommend when compiling TCP Wrappers. First, go with paranoid, as this does a reverse lookup for all connections. Second, use the advance configuration, which is actually quite simple. This configuration keeps all the binaries in there original locations, which may be critical for future patches.

Implementing TCP Wrappers will involve editing several files (these examples are based on the advance configuration). First, once compiled, the tcpd binary will be installed in the /usr/local/bin directory. Second, the file /etc/inetd.conf must be configured for which services are to be wrapped (example D). Third, /etc/syslog.conf must be edited for logging tcpd (example E), be sure to touch the file /var/adm/tcpdlog . Last, the access control lists must be created, /etc/hosts.allow and /etc/hosts.deny (example F).

Once all the proper files have been edited and are in place, restart /usr/bin/inetd with kill -HUP. This will restart the daemon with TCP Wrappers in place. Be sure to verify both your ACLs and logging before finishing.

For the Truly Paranoid
I consider the measures discussed above absolutely essential.  By following these steps, you have greatly improved your system's security, congratulations!  Unfortunately, your system is not 100% secure, nor will it ever be.  So, for the truly paranoid, I have added some additional steps you can take.

First we will create the wheel group.  The wheel group is a group of select individuals that can execute powerful commands, such as /usr/bin/su. By limiting the people the can access these commands, you enhance the system security.  To create the group, vi the file /etc/group, create the group wheel, and add the system admins to the group.  Then identify critical system binaries, such as /usr/bin/su.  Change the group ownership to wheel, and the permissions to owner and group executable only (be sure to maintain the suid or guid bit for specific binaries).  For /usr/bin/su, the commands would be:

/usr/bin/chgrp wheel /usr/bin/su
/usr/bin/chmod 4750 /usr/bin/su

* Note: (Don't forget, for su there is actually another binary in /sbin.  For 2.6, this is called /sbin/static.su.  This is the same thing as /usr/bin/su, however the libaries are statically linked, hence the larger file size.  Don't forget to change this file also ).

Second, we will lock down the files .rhosts, .netrc, and /etc/hosts.equiv.  The r commands use these files to access systems.  To lock them down, touch the files, then change the permissions to zero, locking them down. This way no one can create or alter the files. For example,

/usr/bin/touch /.rhosts /.netrc /etc/hosts.equiv
/usr/bin/chmod 0 /.rhosts /.netrc /etc/hosts.equiv

Last,  we want to set the TCP initial sequence number generation parameters.  By truly randomizing the initial sequence number of all TCP connections, we protect the system against session hijacking and ip spoofing.  This is done by setting  TCP_STRONG_ISS=2 in the file /etc/default/inetinit (example G).  By default, the system installs with a setting of 1, which is not as secure.
 

Conclusion
We have covered some of the more basic steps involved in armoring a Solaris box. The key to a secure system is having the minimal software installed, with protection in layers, such as TCP Wrappers. There are many additional steps that can be taken, such as sudo (allows a system administrator to give limited root privileges to user and log their activities), ssh (encrypted rlogin, rcp, and telnet), tripwire (monitor changes in system binaries), and swatch (automated log monitoring and alerts). Remember, no system is truly 100% secure. However, with the steps outlined above, you greatly reduce the security risks.

For more information on how to better armor your Solaris system, check out Peter Galvin's excellent site, the Solaris Security FAQ!

 http://www.sunworld.com/sunworldonline/common/security-faq.html

or at Jason Rhoad's execellent Unix security site at

http://www.sabernet.net/papers/
 

Downloads.
To save you the time and trouble, I have created a script file that will do everything we have discussed in this article.  The script file will go through your Solaris system and make all the above changes, first backing up any changed files.  The script will also implement TCP wrappers for you.  This script detects what processor you are using (Sparc or x86) and what version (2.5.1, 2.6, 2.7) and makes the proper changes.  I recommend this script for new installs only, but may work for systems that are already in production.  Please send all comments or recommendations to lance@spitzner.net

Download armor.tar.Z

I used compress instead of gzip, since compress and uncompress come with the Solaris distribution.
MD5 Checksum for armor.tar.Z  =  f1b977640b08606631d115aa8d0ad7e9

Author's bio
Lance Spitzner enjoys learning by blowing up his Unix systems at home. Before this, he was an Officer in the Rapid Deployment Force, where he blew up things of a different nature. You can reach him at lance@spitzner.net .